Remote Presentation Session Connectionless Oriented Channel Broker

ABSTRACT

This document describes a remote presentation infrastructure. In an exemplary embodiment at least a portion of the data associated with a remote presentation session can be transported via a connectionless oriented channel established between a client and a remote presentation session. In an embodiment, a gateway computer system can be used to route data to and from a remote presentation session. In this embodiment, the gateway computer system can be configured to establish connectionless oriented channels and route data between remote presentation sessions and clients over connectionless oriented channels. In addition to the foregoing, other techniques are described in the claims, the attached drawings, and the description.

CROSS REFERENCE TO RELATED APPLICATIONS

The subject matter described in this document is related to U.S. patentapplication Ser. No. ______ entitled “Span Out Load Balancing Model”(Attorney Docket No. MVIR-0744/332361.01). The contents of which isherein incorporated by reference in its entirety.

BACKGROUND

Resources on a server can be shared with a client computing device usingremote presentation technologies. One exemplary remote presentationsession is called a remote desktop session. In such a session a desktopis spawned on a server and a communication channel is establishedbetween the server and a client. In this type of a session the clientinteracts with the desktop by sending keyboard strokes and mouse clicksto the server. Images indicative of the graphical user interface of thedesktop are received from the server and displayed by the client.

Another type of remote presentation session is called a remoteapplication session. A remote application session is similar to a remotedesktop session in that user input is sent to the server; however, agraphical user interface for an application is sent to the clientinstead of an entire desktop. As might be expected, the user is limitedto interacting a single application rather than a desktop in this typeof session.

In addition to the foregoing, another exemplary remote presentationsession is called a virtual desktop session. A virtual desktop sessionis similar to a remote desktop session with a few notable differences.For example, a user does not share an operating system with other usersin a virtual desktop session; rather, the user has a console sessionrunning within a virtual machine. As such, a virtual desktop session canbe thought of as a personal computer environment that has its graphicaluser interface sent to the client.

SUMMARY

At a high-level of abstraction, this document describes a remotepresentation infrastructure. In an exemplary embodiment, at least aportion of the data associated with a remote presentation session can besent via a connectionless channel established between a client andserver and other data can be transported via a connection based channel.Accordingly, in an exemplary embodiment, multiple channels can be usedto transport data for a remote presentation session.

In an exemplary configuration, a Remote Desktop Gateway computer systemcan straddle a firewall that prevents remote presentation servers frombeing directly accessed by clients coupled to a public network, such asthe Internet. The Remote Desktop Gateway computer system can includemultiple network interface cards: one having a public IP address and theother having a private IP address. Clients can communicate with thepublic network interface card and the Remote Desktop Gateway computersystem can communicate with the remote presentation servers via theprivate network interface card on behalf of the clients. In anembodiment, the Remote Desktop Gateway computer system can include abroker, which can be configured to receive datagrams and route them tothe correct destination. For example, the broker can receive datagramsfrom clients and route the data stored therein to the correct remotepresentation server. Similarly, the broker can receive datagrams fromremote presentation servers and route the data contained therein to thecorrect clients. In addition to the foregoing, other techniques aredescribed in the claims, the attached drawings, and the description.

It can be appreciated by one of skill in the art that one or morevarious aspects of the disclosure may include but are not limited tocircuitry and/or programming for effecting the herein-referencedaspects; the circuitry and/or programming can be virtually anycombination of hardware, software, and/or firmware configured to effectthe herein-referenced aspects depending upon the design choices of thesystem designer.

The foregoing is a summary and thus contains, by necessity,simplifications, generalizations and omissions of detail. Those skilledin the art will appreciate that the summary is illustrative only and isnot intended to be in any way limiting.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a high-level block diagram of a computer system.

FIG. 2 depicts a high-level block diagram of an exemplary architecturefor a virtualizing software program.

FIG. 3 depicts a high-level block diagram of an alternative architecturefor a virtualizing software program.

FIG. 4 depicts a high-level block diagram of an exemplary remote desktopserver.

FIG. 5 depicts a high-level block diagram of an exemplary virtualdesktop server.

FIG. 6 depicts a high-level block diagram of an exemplary client.

FIG. 7 depicts a high-level block diagram of an operational environmentfor describing broker techniques.

FIG. 8 depicts a specific example of the data that could be found inmapping tables.

FIG. 9 illustrates an operational procedure for establishing aconnection oriented channel and a connectionless channel on a RemoteDesktop Gateway.

FIG. 10 illustrates an operational procedure for transporting data via aconnectionless channel to a remote presentation session.

FIG. 11 illustrates an operational procedure transporting data via aconnectionless channel to a client.

DETAILED DESCRIPTION

The term circuitry used throughout can include hardware components suchas hardware interrupt controllers, hard drives, network adaptors,graphics processors, hardware based video/audio codecs, and the firmwareused to operate such hardware. The term circuitry can also includemicroprocessors, application specific integrated circuits, andprocessors, e.g., an execution unit that reads and executesinstructions, configured by firmware and/or software. Processor(s) andthe like can be configured by instructions loaded from memory, e.g.,RAM, ROM, firmware, and/or mass storage, and the instructions can embodylogic operable to configure the processor to perform one or morefunction. A specific example of circuitry can include a combination ofhardware and software. In this specific example, an implementer maywrite source code embodying logic that is subsequently compiled intomachine readable code that can be executed by the processor.

One skilled in the art can appreciate that the state of the art hasevolved to a point where there is little difference between functionsimplemented in hardware and functions implemented in software (which aresubsequently executed by hardware). As such, the description offunctions as being implemented in hardware or software is merely adesign choice. Simply put, since a software process can be transformedinto an equivalent hardware structure and a hardware structure canitself be transformed into an equivalent software process, functionsdescribed as embodied in instructions could alternatively be implementedin hardware and vice versa.

Referring now to FIG. 1 through FIG. 6, these figures illustratesuitable exemplary operational environments that can be used to embodytechniques for sending remote presentation session data viaconnectionless channels, e.g., via user datagram protocol (“UDP”) baseddatagrams. For ease of understanding, the figures are organized suchthat FIG. 1 through FIG. 6 describe exemplary execution environments,FIG. 7-8 provide further detail, and FIG. 9-11 describe operationalprocedures.

Turning now to FIG. 1, it shows an exemplary computer system 100.Computer system 100 can include processor 102, e.g., an execution core(while one processor 102 is illustrated, in other embodiments computersystem 100 may have multiple processors, e.g., multiple execution coresper processor substrate and/or multiple processor substrates that couldeach have multiple execution cores). In addition to processor 102,computer system 100 can include various computer-readable storage media110, which can be interconnected by one or more system buses that couplevarious system components to the processor 102. The system buses may beany of several types of bus structures including a memory bus or memorycontroller, a peripheral bus, and a local bus using any of a variety ofbus architectures. In example embodiments the computer-readable storagemedia 110 can include for example, random access memory (“RAM”) 104,storage device 106, e.g., electromechanical hard drive, solid state harddrive, etc., firmware 108, e.g., FLASH RAM or ROM, and removable storagedevices 118 such as, for example, CD-ROMs, floppy disks, DVDs, FLASHdrives, external storage devices, etc. It should be appreciated by thoseskilled in the art that other types of computer readable storage mediacan be used such as magnetic cassettes, flash memory cards, and/ordigital video disks.

The computer-readable storage media 110 can provide non volatile and/orvolatile storage of processor executable instructions 122, datastructures, program modules and other data for the computer 100. A basicinput/output system (‘BIOS”) 120, containing the basic routines thathelp to transfer information between elements within the computer system100, such as during start up, can be stored in firmware 108. A number ofprograms may be stored on firmware 108, storage device 106, RAM 104,and/or removable storage devices 118. These programs can include anoperating system and/or application programs. In a specific embodiment,computer-readable storage media 110 of a Remote Desktop Gateway servercan store broker 702, which is described in more detail in the followingparagraphs. In this example embodiment, broker 702 can be executed byprocessor 102 thereby transforming computer system 100 into a computersystem configured for a specific purpose, i.e., a computer systemconfigured according to techniques described in this document.

Commands and information may be received by computer 100 through inputdevices 116, e.g., a keyboard and a mouse. Other input devices mayinclude a microphone, joystick, game pad, scanner or the like. These andother input devices are often connected to processor 102 through aserial port interface that is coupled to the system bus, but may beconnected by other interfaces, such as a parallel port, game port, oruniversal serial bus (“USB”). A display or other type of display devicecan also be connected to the system bus via an interface, such as a DVIinterface which can be connected to a graphics processor unit 112. Inaddition to the display, computers typically include other peripheraloutput devices, such as speakers and printers (not shown). The exemplarysystem of FIG. 1 can also include a host adapter, a Small ComputerSystem Interface (“SCSI”) bus, and an external storage device connectedto the SCSI bus.

Computer system 100 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer.The remote computer may be another computer, a server, a router, anetwork PC, a peer device or other common network node, and typicallycan include many or all of the elements described above relative tocomputer system 100.

When used in a LAN or WAN networking environment, computer system 100can be connected to the LAN or WAN through network interface card 114.The NIC 114, which may be internal or external, can be connected to thesystem bus. In a networked environment, program modules depictedrelative to the computer system 100, or portions thereof, may be storedin the remote memory storage device. It will be appreciated that thenetwork connections described here are exemplary and other means ofestablishing a communications link between the computers may be used.Moreover, while it is envisioned that numerous embodiments of thepresent disclosure are particularly well-suited for computerizedsystems, nothing in this document is intended to limit the disclosure tosuch embodiments.

Turning to FIG. 2 and FIG. 3, illustrated are exemplary virtualizationplatforms that can be used to generate the virtual machines used to hostvirtual desktop sessions. In this embodiment, hypervisor microkernel 202can be configured to control and arbitrate access to the hardware ofcomputer system 200. Hypervisor microkernel 202 can generate executionenvironments called partitions such as child partition 1 through childpartition N (where N is an integer greater than 1). Here, a childpartition is the basic unit of isolation supported by hypervisormicrokernel 202. Hypervisor microkernel 202 can isolate processes in onepartition from accessing another partition's resources. Each childpartition can be mapped to a set of hardware resources, e.g., memory,devices, processor cycles, etc., that is under control of the hypervisormicrokernel 202. In embodiments hypervisor microkernel 202 can be astand-alone software product, a part of an operating system, embeddedwithin firmware of the motherboard, specialized integrated circuits, ora combination thereof.

Hypervisor microkernel 202 can enforce partitioning by restricting aguest operating system's view of the memory in a physical computersystem. When hypervisor microkernel 202 instantiates a virtual machine,it can allocate pages, e.g., fixed length blocks of memory with startingand ending addresses, of system physical memory (SPM) to the virtualmachine as guest physical memory (GPM). Here, the guest's restrictedview of system memory is controlled by hypervisor microkernel 202. Theterm guest physical memory is a shorthand way of describing a page ofmemory from the viewpoint of a virtual machine and the term systemphysical memory is shorthand way of describing a page of memory from theviewpoint of the physical system. Thus, a page of memory allocated to avirtual machine will have a guest physical address (the address used bythe virtual machine) and a system physical address (the actual addressof the page).

A guest operating system may virtualize guest physical memory. Virtualmemory is a management technique that allows an operating system to overcommit memory and to give an application sole access to a contiguousworking memory. In a virtualized environment, a guest operating systemcan use one or more page tables to translate virtual addresses, known asvirtual guest addresses into guest physical addresses. In this example,a memory address may have a guest virtual address, a guest physicaladdress, and a system physical address.

In the depicted example, parent partition component, which can also bealso thought of as similar to domain 0 of Xen's open source hypervisorcan include a host 204. Host 204 can be an operating system (or a set ofconfiguration utilities) and host 204 can be configured to provideresources to guest operating systems executing in the child partitions1-N by using virtualization service providers 228 (VSPs). VSPs 228,which are typically referred to as back-end drivers in the open sourcecommunity, can be used to multiplex the interfaces to the hardwareresources by way of virtualization service clients (VSCs) (typicallyreferred to as front-end drivers in the open source community orparavirtualized devices). As shown by the figures, virtualizationservice clients execute within the context of guest operating systems.However, these drivers are different than the rest of the drivers in theguest in that they may be supplied with a hypervisor, not with a guest.In an exemplary embodiment the path used to by virtualization serviceproviders 228 to communicate with virtualization service clients 216 and218 can be thought of as the virtualization path.

As shown by the figure, emulators 234, e.g., virtualized IDE devices,virtualized video adaptors, virtualized NICs, etc., can be configured torun within host 204 and are attached to resources available to guestoperating systems 220 and 222. For example, when a guest OS touches amemory location mapped to where a register of a device would be ormemory mapped device, hypervisor microkernel 202 can intercept therequest and pass the values the guest attempted to write to anassociated emulator. Here, the resources in this example can be thoughtof as where a virtual device is located. The use of emulators in thisway can be considered the emulation path. The emulation path isinefficient compared to the virtualized path because it requires moreCPU resources to emulate device than it does to pass messages betweenVSPs and VSCs. For example, the hundreds of actions on memory mapped toregisters required in order to write a value to disk via the emulationpath may be reduced to a single message passed from a VSC to a VSP inthe virtualization path.

Each child partition can include one or more virtual processors (230 and232) that guest operating systems (220 and 222) can manage and schedulethreads to execute thereon. Generally, the virtual processors areexecutable instructions and associated state information that provide arepresentation of a physical processor with a specific architecture. Forexample, one virtual machine may have a virtual processor havingcharacteristics of an Intel x86 processor, whereas another virtualprocessor may have the characteristics of a PowerPC processor. Thevirtual processors in this example can be mapped to processors of thecomputer system such that the instructions that effectuate the virtualprocessors will be backed by processors. Thus, in an embodimentincluding multiple processors, virtual processors can be simultaneouslyexecuted by processors while, for example, other processor executehypervisor instructions. The combination of virtual processors andmemory in a partition can be considered a virtual machine.

Guest operating systems (220 and 222) can be any operating system suchas, for example, operating systems from Microsoft®, Apple®, the opensource community, etc. The guest operating systems can includeuser/kernel modes of operation and can have kernels that can includeschedulers, memory managers, etc. Generally speaking, kernel mode caninclude an execution mode in a processor that grants access to at leastprivileged processor instructions. Each guest operating system can haveassociated file systems that can have applications stored thereon suchas terminal servers, e-commerce servers, email servers, etc., and theguest operating systems themselves. The guest operating systems canschedule threads to execute on the virtual processors and instances ofsuch applications can be effectuated.

Referring now to FIG. 3, it depicts similar components to thoseillustrated in FIG. 2; however, in this example configuration,hypervisor 302 can include a microkernel component and componentssimilar to those in host 204 of FIG. 2 such as the virtualizationservice providers 228 and device drivers 224, while management operatingsystem 304 may contain, for example, configuration utilities used toconfigure hypervisor 302. In this architecture, hypervisor 302 canperform the same or similar functions as hypervisor microkernel 202 ofFIG. 2 and host 204. Hypervisor 302 of FIG. 3 can be a stand alonesoftware product, a part of an operating system, embedded withinfirmware of a motherboard, and/or a portion of hypervisor 302 can beeffectuated by specialized integrated circuits.

Referring now to FIG. 4, it illustrates a remote desktop server 400 thatcan be used to simultaneously host multiple remote desktop sessions.Briefly, remote desktop server 400 can include circuitry configured toeffectuate remote desktop sessions for M clients (where M is also aninteger greater than 1). A remote desktop session can generally includean operational environment for a user to execute applications that arestored on remote desktop server 400. In contrast to a computer systemrunning a console session, e.g., a session where a user is logged into acomputer physically located with the user, each remote desktop sessionhas limited control of remote desktop server 400. For example, a usermay not be able to change certain configuration settings, e.g., registrysettings, for operating system 414, install applications, etc.

As shown in the figure, some components of operating system 414 can berun within the context of a session and others can be run as system-wideprocesses. For example, components such as kernel 420, a file system(not shown), authentication subsystem 424, a scheduler (not shown),resource Broker 404, etc., can be run as system-wide processes. Inoperation, some components can be instantiated on a per-session basisand interact with the system-wide processes in order to run programs,open/close files, etc.

A session can be spawned in response to receipt of a transmissioncontrol protocol (“TCP”) Internet protocol (“IP”) connection request bynetwork interface card 412. After receipt of the request it can berouted to a TCP port that remote presentation engine 406 is listeningon. Next, remote presentation engine 406 can forward connection orientedmessages to session manager 408, which can instantiate a remote desktopsession for the connection. For example, session manager can generate asession identifier; add the session identifier to a table; assign memoryto the session space; generate system environment variables andinstances of subsystem processes in memory assigned to the session,e.g., session manager 408 can start an instance of an operating systemAPI 410 and remote display driver 418. Session manager 408 can thencause a logon procedure to start within the session. Meanwhile, remotepresentation engine 406 can instantiate a protocol stack instance forthe session, e.g., stack instance 1, that can send graphical userinterface information for the session to the connecting client andinject data, e.g., mouse clicks, keyboard strokes, etc., received fromthe client into OS API 410.

In embodiments of the present disclosure, remote desktop server 400 mayalso receive a user datagram protocol (“UDP”) IP connection request.Briefly, and described in more detail in subsequent paragraphs, at leasta portion of the data for a remote presentation session can betransported via a connectionless oriented channel such as a UDP/IPchannel. As such, a UDP/IP channel needs to be established prior to itbeing used. Accordingly, network interface card 412 can receive theUDP/IP connection request, which can be addressed to a UDP portassociated with resource broker 404 and addressed from a UDP portassociated with a connection object on a Remote Desktop Gateway (whichis described in more detail in subsequent paragraphs). This connectionrequest can be routed to remote presentation engine 406 and validated.Next, resource broker 404 can receive a session identifier from remotepresentation engine 406 and store in mapping table 416 in associationwith the network address for the connection object. Subsequent UDPdatagrams from this connection object can be routed to the stackinstance associated with this session, i.e., stack instance 1.Subsequent data that is to be sent via a connectionless channel can berouted to resource broker 404, which in turn can send the data indatagrams addressed to the connection object.

After a credential, e.g., a username/password combination, associatedwith a user is validated, authentication subsystem 424 can generate asystem token. This system token can be used whenever the client attemptsto execute a process to determine whether the client has the securitycredentials to run the process. For example, when a process or thread ofa session attempts to gain access, e.g., open, close, delete, and/ormodify an object, e.g., a file, a setting, or an application, the threador process can be authenticated by authentication subsystem 424. Duringan authentication operation, authentication subsystem 424 can check thesystem token against an access control list associated with the objectand determine whether the thread has permission based on a comparison ofinformation in the system token and the access control list. Ifauthentication subsystem 424 determines that the thread is authorizedthen the thread can be allowed to access the object.

Continuing with the description of FIG. 4, in an embodiment the OSapplication program interface can include an input subsystem (notshown). The input subsystem in an example embodiment can be configuredto receive user input from a client via the protocol stack instanceassociated with the session and inject the input to OS API 410. The userinput can include signals indicative of absolute and/or relative mousemovement commands, mouse coordinates, mouse clicks, keyboard signals,joystick movement signals, etc. Draw commands can be issued by OS API410 as well as applications to an application program interface such asDirectD3®. The application program interface can issue commands to agraphics driver running in kernel space and/or within the session. Agraphics processing unit can generate an image that can be captured byremote display driver 418, which can send the image to the stackinstance for the session. The stack instance can in turn send the imageto network interface card 412, which can send the image to the clientvia an private network or a Remote Desktop Gateway server, as describedin subsequent paragraphs.

Turning to FIG. 5, it illustrates an exemplary virtualization desktopserver 500 configured to conduct a plurality of virtual desktop sessionswith a plurality of clients (while one virtual machine is illustrated,virtual desktop server 500 can simultaneously host many virtualmachines). FIG. 5 shows virtualization system 502, which can be thoughtof as a high-level representation of the virtualization platformillustrated by FIG. 2 or FIG. 3. For example, virtualization system 502can be though of as representing the elements shown in FIG. 2 such ashypervisor microkernel 202 and host 204 as well as the componentsillustrated as within hypervisor microkernel 202 and host 204.Alternatively, virtualization system 502 can be thought of asrepresenting the components depicted as included within of hypervisor302 and management OS 304.

A brief comparison of FIG. 4 to FIG. 5 reveals that the components usedto effectuate remote desktop sessions can be used to generate virtualdesktop sessions. For example, both virtual desktop server 500 andremote desktop server 400 include remote presentation engine 406,session manager 408, resource broker 404, etc. One noticeable differenceis that a user conducting a virtual desktop session has a consolesession and is the only individual accessing the guest operating system.As such, the user logged into guest operating system 506 may be in totalcontrol of virtual machine 504. That is, the user can run as anadministrator having full rights on guest operating system 506 and doesnot have to compete with other users logged into guest operating system506 for access to resources provided by guest operating system 506. Auser conducting a remote desktop session, on the other hand, does nothave full control of the operating system and interacts with acustomized server version of an operating system. Also, a remote desktopsession deployment involves configuring a server operating system toallow multiple users to logon to the same operating system asnon-administrators to use its resources.

Referring now to FIG. 6, it illustrates a high-level block diagram of aclient that can be used to conduct a remote presentation session with aremote presentation server such as virtual desktop server 500 or remotedesktop server 400. In a specific example, computing device 602 can besimilar to a desktop computer system, a laptop computer system, a tabletcomputer system, a mobile device (such as a cellular phone), etc. Assuch, computing device 602 can include some or all of the componentsthat computer system 100 of FIG. 1 includes.

In addition to the components illustrated with respect to FIG. 1,computing device 602 can include remote presentation client 620. In anembodiment, remote presentation client 620 can be an application storedin memory that can be executed by an operating system. In anotherembodiment, remote presentation client 620 can be a monolithicapplication that executes without use of a general purpose operatingsystem. In the former exemplary embodiment, when a user runs remotepresentation client 620 it requests resources from an operating system.In the latter exemplary embodiment, remote presentation client 620 maydirectly control the hardware of computing device 602.

Remote presentation client 620 is illustrated as including multiplesubsystems that operate in concert to effectuate the client-side part ofa remote presentation session. Namely, remote presentation client 620can include clipboard subsystem 606, device redirection subsystem 608,display subsystem 618, input capture subsystem 622, and audio subsystem624. Remote presentation client 620 may include other subsystems and thedisclosure is not limited to those illustrated by FIG. 6. Briefly,display subsystem 618 can be used to display images received from theserver and audio subsystem 624 can be configured to receive a stream ofaudio data generated by a music player or the like running on the remotepresentation server and output it to speakers attached to computingdevice 602. Similarly, clipboard subsystem 606 can be configured toallow copy and/or cut-and-paste operations to take place between remotepresentation server and computing device 602. For example, a user couldcopy a document stored on the desktop of a virtual desktop server to adesktop of computing device 602.

In operation, the aforementioned subsystems can use remote presentationengine 610 to communicate with a remote presentation server. Forexample, input capture subsystem 622 can obtain mouse clicks andkeyboard strokes and send them to remote presentation engine 610, whichcan encode the data according to protocol such as the remote desktopprotocol (“RDP”) into a RDP message that can be sent it off to theserver. Similarly, RDP messages including data for the remotepresentation session, e.g., a graphical user interface of a wordprocessing program, can be received by remote presentation engine 610and decoded. Next, the data can be sent to the appropriate subsystem,e.g., images can be sent to display subsystem 618 and a display ofcomputing device 602 can render the graphical user interface of theremote presentation session.

Similar to the remote presentation servers described above, a connectionbased channel and one or more connectionless channels can be opened onthe client for a remote presentation session. In an embodiment, eachconnectionless channel can be associated with an endpoint object andeach endpoint object can be bound to a different UDP port. For example,and turning to endpoint objects 628 and 630, these objects can beinstantiated and configured to route data in datagrams to and fromremote presentation engine 610. Endpoint object 628 can bind to UDP port614 and endpoint object 630 can bind to UDP port 628. As such, each UDPconnection will have a different network address. By assigning eachconnectionless channel to a different network address data indicative ofa remote presentation session can be allowed to flow to the remotepresentation server through one or more Remote Desktop Gateway servers.

Turning back to endpoint objects 628 and 630, remote presentation engine610 can maintain a table that maps data from different subsystems toendpoint objects. For example, remote presentation engine 610 mayinclude a table that maps display system 618 to endpoint object 628 andaudio subsystem 624 to endpoint object 630. As such, when data sent viaUDP datagrams is generated by remote presentation engine 610 it can berouted to the correct endpoint object. Next, the endpoint object cancause a datagram to be generated that includes the data. The datagramcan be is addressed to a network address of the Remote Desktop Gateway(or a load balancer) and addressed from the unique network address forthe associated endpoint object. Finally, network interface card 604 cansend the datagram to the network address. In a specific example, supposethat the table maps display system 618 to endpoint object 628. In thiscase, if a user generates video, e.g., using a video capture device orthe like, messages can be routed to endpoint object 628, which can sentthem in UDP/IP packets addressed from the IP address of networkinterface card 604 and the port number for UDP port 614 to a networkaddress of a Remote Desktop Gateway.

UDP datagrams can also be received by network interface card 604 androuted to the appropriate endpoint object. For example, a datagramaddressed to UDP port 614 or UDP port 626 can be received by networkinterface card 604 and routed through the network stack to theappropriate endpoint object. After receiving a message stored in thedatagram, the endpoint object can route it to remote presentation engine610. Next, remote presentation engine 610 can decode the message andpass the data stored therein to the appropriate subsystem forprocessing.

Turning now to FIG. 7, it illustrates a Remote Desktop Gateway server(gateway 700) that can be used to allow clients (computing devices752-758) coupled to a public network, such as the Internet, tocommunicate with one or more remote presentation servers, e.g., virtualdesktop server 736 and/or remote desktop server 734, which can beconnected to a private network. Briefly, gateway 700 can includecomponents similar to computer system 100 of FIG. 1. As an aside, in atypical deployment, a corporate entity may control multiple RemoteDesktop Gateway computer systems. Each gateway can be functionallyequivalent to gateway 700 and one is illustrated in FIG. 7 for the sakeof simplicity.

Discussed briefly above, at least a portion of the data for a remotepresentation session can be transported via a connectionless channel.Generally, an implementer can select any type of data to be sent via aconnectionless channel. However, in an exemplary embodiment, animplementer may choose to separate data into data that can tolerate lossand data that cannot and send data that cannot tolerate loss via TCPbased IP packets and data that can tolerate loss via UDP datagrams.Specific examples of data that can be sent via a connectionless channelcan include data indicative of audio (music played on a server andstreamed to a client), video (Flash video, HTML 5 video, etc.), imagesindicative of a graphical user interface (a bitmap indicative of adesktop), etc. Specific examples of data that can be sent via aconnection oriented channel can include data indicative of keyboardstrokes, mouse movements, cut-and-paste data, etc.

One reason for sending at least a part of the data for a remotepresentation session via UDP datagrams is because UDP traffic can betransported faster than TCP traffic. For example, UDP based packets aresent without establishing a connection and dropped packets are notresent. In effect, data is simply packaged into a UDP datagram;encapsulated in an IP packet; and sent to a destination IP address/portnumber combination. The need for sending data quickly may arise whendata that is sensitive to lag is being transported, such as dataindicative of audio, video, etc. A downside to using UDP datagrams isthat there no guarantee that each datagram will be delivered. As such,lost data is not retransmitted.

Turning back to the description of FIG. 7, broker 702 can be used toconfigure gateway 700 to handle both TCP and UDP traffic for a remotepresentation session. For example, broker 702 can be configured tolisten on UDP port 730, which can be used by computing devices 752-758to send datagrams to gateway 700. Accordingly, gateway 700 can use asingle UDP port to receive datagrams sent from a plurality of clients.By multiplexing UDP packets through a single UDP port rather thanopening a UDP port on gateway 700 for each client, the attack surface ofgateway 700 is reduced and the administration costs associated withtracking open ports is minimized.

After datagrams are received by broker 702, it can demultiplex UDPdatagrams into separate streams using mapping table 718 and connectionobjects 710-716. Similar to endpoint objects, an instance of aconnection object can be instantiated for each connectionless orientedchannel established with a client. For example, FIG. 7 shows connectionobjects 710-716, each of which may be associated with a connectionlesschannel (in the illustrated example each computing device 752-758 isshown as having one connectionless channel; however, a client may haveone or more connectionless oriented channels on a Remote Desktop Gatewayand each connectionless channel can be associated with a connectionobject). When a UDP based connection request is received by gateway 700,broker 702 can instantiate a connection object and assign it a sockethandle. Once instantiated, a connection object can bind to a portassociated with network interface card 704, i.e., a port on the privateIP network. Briefly, network interface card 704 can be coupled to aprivate network and have a private IP address, i.e., network interfacecard 704 can be connected to a network that uses a private IP addressspace that is not globally delegated nor can devices operating on theprivate IP address space be directly accessed by a public network suchas the Internet. In addition, each connection object can be instantiatedwith the IP address/port number combination for the remote presentationsession. As such, each connection object can include information thatenables it to route data to the appropriate remote presentation session.

In a specific example, suppose that a UDP based connection request isreceived from computing device 752 and the connection request indicatesthat computing device 752 is attempting to connect to remote desktopserver 734. In response to receipt of this request, broker 702 caninstantiate connection object 710 with the network address for remotedesktop server 734 and connection object 710 can bind a private UDP port(e.g., UDP port 744). As such, connection object 710 can be configuredto listen on a private UDP port for UDP datagrams sent by remote desktopserver 734 that are for computing device 752 and send UDP datagrams tothe network address of remote desktop server 734.

In an embodiment, broker 702 can use mapping table 718 to determine howto route UDP datagrams from clients to the correct connection object andvice versa. Turning to FIG. 8, it illustrates a specific example of thetype of information that can be stored in mapping table 718. As shown bythe figure, in an embodiment mapping table 718 can include a connectionidentifier for each client. The connection identifier can be formeddirectly from a network address for each client, e.g., an IP addressport number combination for the client and a socket handle for theconnection object that is emulating a connection between gateway 700 andthe remote presentation session. Alternatively, a connection identifiercan be assigned by the gateway as, for example, a unique numerical valueas illustrated in mapping table 718 of FIG. 8. In addition to theforegoing, mapping table 718 can include information such as the sessionidentifier, the username/password combination used by client, thenetwork address for the associated remote presentation server, etc. Someor all of this information in mapping table 718 can be used to determinewhere to route data contained in a given datagram.

Similarly, resource mapping table 762 can also include a connectionidentifier, a Remote Desktop Gateway address, e.g., a private IP addressport number combination, used by an associated connection object and asession identifier generated by the remote presentation server. Resourcebroker 764 and 768 can be similar to resource broker 760; however,resource broker 764 and 768 may host a single session since each virtualdesktop session runs in its own virtual machine having its own virtualnetwork interface card. In the illustrated example, each client isillustrated as having one UDP channel; however, each client may havemultiple channels established through a Remote Desktop Gateway. As such,mapping table 718, 762, 766, and/or 770 may have routing information formultiple connectionless channels that are associated with the sameconnection identifier.

Continuing with the description of FIG. 7, in an embodiment gateway 700can use access subsystem 724, remote presentation gateway client 720,and encryption subsystem 774 to establish a remote presentation session.In an exemplarily configuration, access subsystem 724 can determinewhether to forward a connection request to a remote presentation server.As such, access subsystem 724 acts as a first gatekeeper.

Turning now to FIG. 9 it illustrates an operational procedure forestablishing a connection oriented channel and a connectionless orientedchannel between a client and a remote presentation server. Operation 900begins the operational procedure and operation 902 illustrates thatgateway 700 can include circuitry configured to receive a request for aremote presentation session from a client. For example and turning toFIG. 7, in a specific example access subsystem 724, e.g., by executableinstructions run by a processor, can receive a connection request for aremote presentation session from network interface card 706.

Suppose that a user operating a client, such as computing device 752(which may have components similar to computing device 602) desires aremote presentation session. Here, the user may open a web-browser andnavigate to a webpage associated with the entity offering remotepresentation services that includes a link for establishing a session.In response to a selection of the link, the client can send a HTTPSconnection request to an IP address TCP port number combinationassociated with access subsystem 724. In a specific example, the IPaddress can be associated with network interface card 706 and the portnumber can be for TCP port 726. Network interface card 706 of FIG. 7 canreceive one or more packets indicative of a connection request. Anetwork stack can extract the TCP packet from the IP packet; extract thepayload (i.e., a HTTPS message) from the TCP packet; and route thepayload to access subsystem 724, which could be bound to TCP port 726 inthis example.

Access subsystem 724 can receive the connection request and extract ausername/password combination from the HTTPS message. Theusername/password combination can be authenticated and access subsystem724 can allow a properly authenticated connection to connect to therequested resource. In a typical, remote presentation session, therequested resource will initially request a connection to a connectionbroker 725 or the like. The connection broker 725, will select asuitable remote desktop server 734 or virtual desktop server 736 to hostthe session. For example, if the request indicates that a remote desktopsession or a remote application session is desired, the connectionbroker 725 will search a database that includes IP address port numbercombinations for remote desktop servers to find a remote desktop server.Similarly, if the request is for a virtual desktop session, connectionbroker 725 can search a database that includes network identifiers forvirtual desktop servers to find a virtual desktop server. In a specificexample, suppose that the request is for a remote desktop session andconnection broker 725 selects remote desktop server 734 to host thesession. For example, connection broker 725 can generate a redirectionrequest that causes the client to send one or more connection requeststo one or more IP address port number combinations for gateway 700 toconnect to remote desktop server 734.

After establishing the TCP/IP connection with the remote desktop server734, in accordance with an aspect of the invention, it may be desirableto open a second connection with the remote desktop server 734 inaccordance with a particular session established between the client oncomputing device 752 and the remote desktop server 734. As such, arequest will be made to the gateway to open a second connection to theremote desktop server 734. The request can originate from the remotedesktop server 734, the computing device 752, or both.

In addition to a TCP/IP based connection request, the second connectionrequest may be for one or more UDP based channels to gateway 700. In anembodiment, remote presentation client 620 can be configured to use oneconnectionless oriented channel to transport data that can tolerateloss; however, in an alternative embodiment, remote presentation client620 can be configured to open multiple connectionless oriented channels.In a specific example, remote presentation client 620 can open aconnectionless oriented channel for audio, a connectionless orientedchannel for video, and/or a connectionless oriented channel for agraphical user interface. Here, endpoint objects can be spawned and eachendpoint object can bind to a port. After successfully binding to ports,the endpoint objects can send connection requests to gateway 700 via UDPdatagrams.

After the TCP connection is established, access subsystem 724 cangenerate a package (e.g., a HTML cookie, an XML document, etc.) that caninclude configuration information to start a session. For example, theconfiguration information can include the private network address usedby remote desktop server 734, a copy of the username/passwordcombination, a connection identifier, and a timestamp. This informationcan be encoded within a package and then digitally signed by encryptionsubsystem 774 using a copy of a key. For example, encryption subsystem774 can generate a hash of the data stored in the package and encryptthe hash with an encryption key. The encrypted hash, i.e., the digitalsignature, can be embedded in the package and the package can beencrypted.

Next, the encrypted package can be encoded into a response message andsent by network interface card 706 to the client, e.g., computing device752 in a specific example. Turning to FIG. 6, the client can include anetwork stack that can process the IP packet(s) and extract the responsemessage. The package can then be routed to connection subsystem 626 andstored in computer-readable storage medium 110, e.g., the encryptedcookie can be stored in random access memory 104. Remote presentationclient 620 can then send a connection message to the IP address portnumber combinations in the request message.

Referring to operation 906 of FIG. 9, it indicates that gateway 700 caninclude circuitry configured to establish connection oriented channel tothe client. For example and turning back to FIG. 7, network interfacecard 706 can receive the connection request and route it to remotepresentation gateway client 720, which may be configured to listen toTCP port 728. Remote presentation gateway client 720 in turn can obtainthe connection message and route it to connection manager 722. Next,connection manager 722 can send the package to encryption subsystem 772,which can decrypt the encrypted package using a key and validate adigital signature stored in the package. In addition, connection manager722 can compute the difference between the timestamp in the decryptedpackage and the current time and compare the difference to a threshold,e.g., 5 minutes.

In the instance that the digital signature is valid, and the timestampdifference is less than the threshold, connection manager 722 canvalidate the package and initiate a connection sequence between gateway700 and the client, e.g., computing device 752. For example, connectionmanager 722 can generate a socket handle for the connection andassociate it with the connection identifier. After the TCP/IP connectionsequence completes, a message can be sent back to the client indicatingthat the connection oriented channel was established.

Remote presentation gateway client 720 can route a connection request tothe selected remote presentation server that can include a copy of theusername/password combination for the user. After the connectionsequence between gateway 700 and the selected remote presentation serveris completed, the selected remote presentation server can validate theusername/password combination; assign the session a session identifier;and start a session. As an aside, after the TCP/IP channel is openeddata can flow from the selected remote presentation server, e.g., remotedesktop server 734, to the client, e.g., computing device 752. Forexample, user input data such as keyboard strokes or mouse movementcoordinates can be encoded into a message by the client and sent via aTCP/IP channel to gateway 700. Connection manager 722 can receive themessage and route it to remote desktop server 734, which can inject theuser input data into the appropriate session. Similarly, suppose that auser copies a document from the remote desktop to computing device 754.In this example, the document can be sent via one or more TCP/IP packetsfrom remote desktop server 734 to gateway 700 and then routed via one ormore TCP/IP packets to computing device 752.

Referring briefly to operation 908, it indicates that gateway 700 canadditionally include circuitry configured to receive datagram from theclient, the datagram addressed from a network address of the client, thedatagram including the package. Turning back to FIG. 7, a connectionrequest can be routed to UDP port 730 and broker 702, which can beconfigured to listen to UDP port 730, can obtain the message. In thisexample, broker 702 detect the package within the request and route theencrypted package to connection manager 722. Next, connection manager722 can route the package to encryption subsystem 774, which can use itscopy of a key to validate the package. Broker 702 can receive thepackage and add the connection identifier to mapping table 718 inassociation with the network address of the client, e.g., computingdevice 752. At this point, a connectionless channel is establishedbetween gateway 700 and computing device 752.

Turning briefly to operation 910 of FIG. 9, it indicates that gateway700 can additionally include circuitry configured to instantiate aconnection object, the connection object associated with a networkaddress for the remote presentation server. For example, broker 702 caninstantiate a connection object for the remote presentation session,e.g., connection object 710 and pass it the network address for theremote presentation server, e.g., remote desktop server 734.

Operation 912 indicates that gateway 700 can additionally includecircuitry configured to associate a socket handle for the connectionobject with the network address for the client. For example, anoperating system running on gateway 700 can generate a socket handle forthe connection object and broker 702 can store it in association withthe connection identifier and the network address for the client. Theconnection object, e.g., connection object 710, can bind to a socketassociated with network interface card 704, i.e., connection object 710can bind to the IP address of network interface card 704 and the portnumber for UDP port 744.

After receiving a signal indicating that the bind operation wassuccessful, the connection object can send the connection request to theremote presentation server. In a specific example, the connectionrequest can include the username/password combination provided by theuser of the client, a client access license, configuration settings forthe session, i.e., information that indicates whether device redirectionis enabled, and other configuration settings. A network interface cardof remote desktop server 734 can receive the connection request androute it to a UDP port that resource broker 404 is bound to. Resourcebroker 404 can receive the connection request; detect the connectionrequest; and forward the payload of the packet, e.g., the remote desktopsession connection request, to remote presentation engine 406. Remotepresentation engine 406 can determine that the payload is similar to aconnection request received via TCP/IP packets and send the sessionidentifier to resource broker 404. Resource broker 404 can store thesession identifier in association with the network address used by theconnection object. After this set of operations completes aconnectionless channel is established between gateway 700 and remotedesktop server 734.

Turning now to FIG. 10, it shows an operational procedure that can beexecuted by gateway 700 in order to transport session data from a clientto a remote presentation server via a connectionless channel. Operation1000 begins the operational procedure and operation 1002 indicates thatgateway 700 can include circuitry configured to receive a datagramaddressed from a network address associated with a client via aconnectionless channel. For example, and referring to FIG. 7, networkinterface card 706 can receive one or more UDP datagrams from a client,such as computing device 758. UDP datagrams can be extracted from the IPpackets and routed to UDP port 730. The payload of the UDP datagrams canthen be detected by broker 702.

Continuing with the description of FIG. 10, decision point 1004indicates that gateway 700 can include circuitry configured to determineif a connectionless channel has been established for the network addressassociated with the client. For example, when a client such as computingdevice 758 sends a UDP datagram to gateway 700, the packet can include anetwork address, e.g., the IP address/port number, that an endpointobject on computing device 758 is using to communicate with gateway 700.The payload of the datagram can be routed to broker 702, which determinewhether the packet includes a connection request. If not, broker 702 canuse the network address associated with the endpoint to determine thesocket handle for the connection object handling datagrams from thisclient. In a specific example and referring to FIG. 8, broker 702 candetermine that mapping table 718 includes an entry mapping the networkaddress for computing device 758 to connection object 716. If thedatagram includes a connection request broker 702 can route the payloadof the datagram to connection manager 722 as described above.

Turning to operation 1006, it shows that gateway 700 can includecircuitry configured to send the payload of the datagram to a connectionobject that is associated with a remote presentation session. Referringto FIG. 7, in a specific example where the datagram is from computingdevice 758, it can be routed to connection object 716.

Turning to operation 1008, it shows that in an embodiment gateway 700can also include circuitry configured to send a datagram to a networkaddress associated with the remote presentation session, the datagramaddressed from a network address associated with the connection object.For example and again referring to FIG. 7, the connection object, e.g.,connection object 716, can send a request to a network stack to send thepayload in a UDP datagram to the network address for the remotepresentation session, e.g., virtual machine 740 in a specific example.In this specific example, connection object 716 may be bound to UDP port750. As such, the UDP datagram sent by network interface card 704 caninclude the private IP address of network interface card 704 and theport number for UDP port 750 in a source address field and an private IPaddress and a UDP port number associated with resource broker 768running in virtual machine 740 in a destination address field.

Suppose that virtual machine 740 is running on a computer system similarto virtual desktop server 500 of FIG. 5. In this example, networkinterface card 412 can receive the UDP datagram addressed from theprivate IP address of network interface card 704 and the port number forUDP port 750 and it can be routed through virtualization system 502 toresource broker 768. Resource broker 768 can parse the source addressfield and determine that the UDP based packet was received fromconnection object 716. As shown in FIG. 8, resource broker 768 can lookin mapping table 770 and determine that the payload is for the virtualdesktop session and route it to an instance of remote presentationengine running within virtual machine 740.

Turning now to FIG. 11, it illustrates an operational procedure that canbe used to route a payload via a connectionless channel between a remotepresentation server to a client. Operation 1100 begins the operationalprocedure and operation 1102 indicates that gateway 700 can includecircuitry for receiving a first datagram addressed to a network addressfor a connection object, the datagram including a payload. For example,and turning to FIG. 7, network interface card 704 can receive a UDPdatagram from a remote presentation server such as remote desktop server734. When a UDP datagram addressed to the IP address for networkinterface card 704 and the port number for UDP port 744 is received itcan be routed to connection object 712. In this example, remote desktopserver 734 could have previously received a UDP datagram that wasaddressed from connection object 712 and resource broker 760 may havestored the network address for connection object 712 in mapping table762.

In a specific example, suppose remote desktop server 734 is effectuatinga remote desktop session for computing device 754. In this example,remote desktop server 734 can encode data indicative of a graphical userinterface, e.g., an image of a desktop, video, e.g., HTML 5 videoembedded within a webpage, audio, e.g., a song being played on remotedesktop server 734, etc., into a remote desktop message. Next, themessage could be sent to resource broker 760 along with a sessionidentifier. Resource broker 760 can use mapping table 762 to determinethe network address for gateway 700, i.e., the network addressassociated with connection object 712, and cause a UDP datagramincluding the remote desktop message to be sent to the determinednetwork address.

Turning back to FIG. 11, operation 1106 indicates that gateway 700 caninclude circuitry configured to determine that a socket handle for theconnection object is associated with a network address for a client.Referring to FIG. 7, connection object 712 can send a signal to broker702 indicating that a remote desktop message was received. Broker 702can obtain the payload and use the socket handle for connection object712 to search mapping table 718. Turning briefly to FIG. 8, here, broker702 can determine that the socket handle for connection object 712 isassociated with network address for computing device 754. Accordingly,broker 702 can send a send request to a network protocol stack to sendthe payload to the network address for computing device 754. The networkstack can generate a UDP datagram having the network address of gateway700, e.g., the IP address of network interface card 706 and the portnumber for UDP port 730, set as the source address and the networkaddress of computing device 754 set as the destination address.

Turning to FIG. 6, suppose that computing device 754 includes componentsthat are similar to computing device 602. As such, network interfacecard 604 of computing device 754 can receive the UDP datagram andextract the remote desktop protocol message stored therein. The messagecan be routed to remote presentation engine 610, which can process thepayload and send it to the appropriate end point. For example, displaysubsystem 618 in the instance that the payload is indicative of an imageor video.

The foregoing detailed description has set forth various embodiments ofthe systems and/or processes via examples and/or operational diagrams.Insofar as such block diagrams, and/or examples contain one or morefunctions and/or operations, it will be understood by those within theart that each function and/or operation within such block diagrams, orexamples can be implemented, individually and/or collectively, by a widerange of hardware, software, firmware, or virtually any combinationthereof.

While particular aspects of the present subject matter described hereinhave been shown and described, it will be apparent to those skilled inthe art that, based upon the teachings herein, changes and modificationsmay be made without departing from the subject matter described hereinand its broader aspects and, therefore, the appended claims are toencompass within their scope all such changes and modifications as arewithin the true spirit and scope of the subject matter described herein.

1. A computer-readable storage medium including instructions that uponexecution by a processor cause a computer system to: receive aconnection request via a datagram addressed to a public network addressof the computer system, the datagram addressed from a client networkaddress for a client, the datagram including a resource network addressfor a remote presentation session in a payload; associate the clientnetwork address with a private network address for the computer systemand the resource network address; receive first data for the remotepresentation session, the data addressed to the private network address;and send the first data via a connectionless oriented channel to theclient network address in response to determining that the privatenetwork address is associated with the client network address.
 2. Thecomputer-readable storage medium of claim 1, further comprisinginstructions that upon execution cause the computer system to: determinethat second data received via the connectionless oriented channel fromthe client is addressed from the client network address; and send thesecond data to the resource network address in response to determiningthat the client network address is associated with the private networkaddress.
 3. The computer-readable storage medium of claim 1, furthercomprising instructions that upon execution cause the computer systemto: receive a second connection request via a second datagram addressedto the public network address of the gateway, the second datagramaddressed from a second client network address for a second client, thesecond datagram including the resource network address in a payload; andassociate the second client network address with a second privatenetwork address for the computer system and the resource networkaddress.
 4. The computer-readable storage medium of claim 1, the firstdata being indicative of a graphical user interface from the remotepresentation session.
 5. The computer-readable storage medium of claim1, the first data being indicative of audio from the remote presentationsession.
 6. The computer-readable storage medium of claim 1, wherein theinstructions that upon execution cause the computer system to receivethe first data for the remote presentation session further compriseinstructions that upon execution cause the computer system to: receivethe first data from a virtual machine executing on a virtual desktopserver.
 7. The computer-readable storage medium of claim 1, wherein theinstructions that upon execution cause the computer system to receivethe first data for the remote presentation session further compriseinstructions that upon execution cause the computer system to: receivethe first data from a remote desktop server.
 8. The computer-readablestorage medium of claim 1, further comprising instructions that uponexecution cause the computer system to: associate the client networkaddress with a connection oriented channel established between theremote presentation session and the client.
 9. A gateway, comprising: aprocessor; and a memory, the memory including executable instructionsstored thereon that upon execution cause the gateway server to: extracta package from a transmission control protocol based packet, thetransmission control protocol based packet addressed from a firstinternet protocol address port number combination for a computingdevice, the package including an internet protocol address port numbercombination for a remote presentation server; establish a transmissioncontrol protocol based channel to the computing device in response tovalidating the package; route first data for a remote presentationsession via the transmission control protocol based channel between thecomputing device and the remote presentation server; receive aconnection request addressed from a second internet protocol addressport number combination for the computing device, the connection requestaddressed to a public network address of the gateway, the connectionrequest including a copy of the package; associate the second internetprotocol address port number combination for the computing device with aprivate internet protocol address port number combination for thegateway server and the internet protocol address port number combinationfor the remote presentation server; receive a first datagram from theremote presentation server, the first datagram including data indicativeof a graphical user interface, the first datagram addressed to theprivate internet protocol address port number combination for thegateway; and send the data in a second datagram to the second internetprotocol address port number combination for the computing device inresponse to determining that the private internet protocol address portnumber combination for the gateway is associated with the secondinternet protocol address port number combination for the computingdevice.
 10. The gateway server of claim 9, wherein the memory furthercomprises instructions that upon execution cause the gateway server to:validate a digital signature stored in the package.
 11. The gatewayserver of claim 9, wherein the memory further comprises instructionsthat upon execution cause the gateway server to: receive a thirddatagram addressed from the second internet protocol address port numbercombination for the computing device and addressed to a public networkaddress of the gateway, the third datagram including second data for theremote presentation session; and send the second data for the remotepresentation session in a fourth datagram to the internet protocoladdress port number combination for the remote presentation server, thefourth datagram addressed from the private internet protocol addressport number combination for the gateway.
 12. The gateway server of claim9, wherein the memory further comprises instructions that upon executioncause the gateway server to: receive data indicative of a file from theremote presentation server; and route the data indicative of the file tothe computing device via the transmission control protocol basedchannel.
 13. The gateway server of claim 9, wherein the memory furthercomprises instructions that upon execution cause the gateway server to:receive user input from the computing device; and send the user input tothe remote presentation server via the transmission control protocolbased channel.
 14. The gateway server of claim 9, wherein the memoryfurther comprises instructions that upon execution cause the gatewayserver to: store a connection identifier that associates the secondinternet protocol address port number combination for the computingdevice with the transmission control protocol based channel.
 15. Acomputer implemented method, comprising: receiving a first payload froma first datagram associated with a first remote presentation session,the first datagram addressed to a first private network address for agateway; send the first payload in a second datagram to a first clientin response to a determination that the first private network addressfor the gateway is associated with a network address for the firstclient, the second datagram addressed from a user datagram protocol portexposed to a public network; receiving a second payload from a thirddatagram associated with a second remote presentation session, the thirddatagram addressed to a second private network address for the gateway;and send the second payload in a fourth datagram to a second client inresponse to a determination that the second private network address forthe gateway is associated with a network address for the second client,the forth datagram addressed from the user datagram protocol portexposed to the public network.
 16. The computer implemented method ofclaim 15, further comprising: validating a cookie obtained fromconnection request sent by the first client, the connection requestaddressed from the network address for the first client and the cookieincluding a network address associated with the first remotepresentation session.
 17. The computer implemented method of claim 15,further comprising: sending data indicative of user input for the firstclient to the first remote presentation session via a connectionoriented channel established between the gateway and the first remotepresentation session.
 18. The computer implemented method of claim 15,further comprising: associating the network address for the client witha connection oriented channel established between the gateway and thefirst client.
 19. The computer implemented method of claim 15, whereinreceiving the first payload from the first datagram further comprises:receiving data indicative of a graphical user interface for the firstremote presentation session.
 20. The computer implemented method ofclaim 15, herein receiving the first payload from the first datagramfurther comprises: receiving data indicative of audio for the firstremote presentation session.